home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98a.txt / 000097_icon-group-sender _Wed Mar 4 16:30:33 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id QAA18123
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Wed, 4 Mar 1998 16:30:33 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA05583; Wed, 4 Mar 1998 16:30:32 -0700
  7. Date: Wed, 04 Mar 98 18:01:37 -0500
  8. Message-Id: <9803042301.AA0102@valinet.com>
  9. From: Paul Abrahams <abrahams@acm.org>
  10. To: icon-group@optima.CS.Arizona.EDU
  11. In-Reply-To: <swampler-9802041641.AA00091256@orpheus.gemini.edu>
  12. Subject: Re: Icon translation
  13. Reply-To: abrahams@acm.org
  14. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  15. Status: RO
  16. Content-Length: 2394
  17.  
  18. >>>>> On Wed, 4 Mar 1998 09:41:45 -0700, swampler@noao.edu (Steve Wampler) said:
  19. |Steve> If you carefully profile Icon programs, you may notice that
  20. |Steve> there's a 'base cost' spread throughout the entire system.  This
  21. |Steve> is what makes it look as though Icon can't be sped up much - a
  22. |Steve> rather high, flat cost foundation.  I believe that a significant
  23. |Steve> fraction of this base cost is due to the use of descriptors in
  24. |Steve> the implementation.  (Don't misunderstand me, I'm not knocking
  25. |Steve> descriptors - they are a *major* factor in the flexibility and
  26. |Steve> power of a language like Icon.)
  27.  
  28. |Steve> If you look at 'most' Icon programs, though, a human can
  29. |Steve> determine that much of the transfer of data in the program can
  30. |Steve> be identified and typed.  This is one of the important features
  31. |Steve> of Ken Walker's Icon-to-C optimizer, removing unneeded type
  32. |Steve> checks.  What that optimizer stops short of doing is removing
  33. |Steve> the unneeded descriptors themselves.
  34.  
  35. |Steve> An *amazingly good* optimizer should be able to strip
  36. |Steve> descriptors from most places (not all) in an Icon program.  With
  37. |Steve> appropriate support from the runtime system, speeds very close
  38. |Steve> to C should be possible from an Icon compiler.
  39.  
  40. Frankly, I think one of the weaknesses of Icon is the lack of strong
  41. typing - or what more accurately I would call "optional strong typing".
  42. Icon already has declarations - they're just not used for data types.  I
  43. could imagine an Icon-like language that differed *only* in having
  44. optional type declarations, with an "any" type that behaves just as Icon
  45. variables now do.  Such a language would, of course, have all the
  46. elegant Icon syntax and control structures.
  47.  
  48. Strong typing would achieve two things: it would provide protection
  49. against a wide class of coding errors, and it would make efficient
  50. compilation possible without elaborate and still incomplete dataflow
  51. analysis to determine run-time types.  And were it optional, what would
  52. be lost?
  53.  
  54. I won't claim that such a language would be Icon; only Icon is Icon.
  55. But it's the language I'd very much like to have.
  56.  
  57. By the way, were Icon++ (or Icon--, if you prefer) to be compiled into C
  58. (the poor man's form of compilation), I would expect that it would *not*
  59. use the C string type because of the problems with null characters.
  60.  
  61. Paul Abrahams
  62. abrahams@acm.org
  63.  
  64.  
  65.